The present invention relates broadly to computer storage devices. Specifically, the present invention relates to configuration of controllers of computer storage devices, and more specifically to a text-based configuration of controllers for storage systems including for redundant arrays of independent disk (RAID) systems.
Controllers for redundant arrays of independent disks (RAID) are currently produced by numerous manufacturers without adherence to any particular configuration standard. The result is that a system requiring more than one RAID controllers may be limited to controllers made by only one manufacturer so that at least a common configuration standard can be used for the multiple controllers, which over time and for systems requiring a large number of RAID controller may become expensive and prevent the system from incorporating RAID controllers that are either less expensive or employ newer and more efficient technologies.
Several obstacles hinder the implementation of a configuration standard. Big-Endian/Little-Endian is a processor attribute that refers to the order in which multi-byte numeric entities are communicated and/or stored in memory. For example, Intel processors are Little-Endian while processors made by Sun, Motorola and other manufacturers are Big-Endian. Many processors have selectable Endianess so that they will work in any given situation. A 32-bit entity needs 4 bytes of memory and a 16-bit entity needs 2 bytes of memory. Big-Endian processors store these multi-byte entities so that the most significant byte is in the lowest addressed byte of the required memory locations with the other bytes stored in decreasing significance order in the remaining higher memory address locations.
The problem with Endianess with respect to disk controller configurations is that controllers can have processors with one Endianess and computers hosting the configuration software can have processors with the other Endianess. Neither processor by itself has direct knowledge of the other and how it handles Endianess so the software in one or both processors must convert to the Endianess of the other. Complexity increases as conventions become involved, and custom software must frequently be created for each different computer system based on the Endianess involved.
Another obstacle to the implementation of a configuration standard is that of atomic storage. Atomic storage is the atomic size problem that may exist in parts of the software that use the configuration data transferred as text and arises when fixed data structures are used. Each item in the data structure will have a fixed size. When text in the configuration is updated to a size that exceeds the data structure the entire data structure must generally be changed and all users of that structure must be updated with the new data structure. This typically means that the software must be recompiled and re-released.
A data structure must be changed in this manner whenever greater range is required of one of the entities. As products evolve they take on greater capabilities and it takes more space to represent those capabilities. An example of this problem is seen where a SCSI disk controller that today supports 16 drives on 10 channels yielding a total of 160 drives. The number xe2x80x9c160xe2x80x9d easily fits in a byte. Upgrading the disk controller to a fibre channel permits the controller to support 125 drives on each of the 10 channels. That makes the number of possible drives equal to 1250 which will no longer fit in the original byte location, as an 8-bit byte can count only 255 items. Thus, the data structure must be changed to expand that byte to something larger. One attempted solution to this problem is to use the largest numeric entities available to hold every item, even when one byte will do. This solution is inefficient when there may be a large number of such items to transfer.
Data structure packing is yet another problem. Data structure packing refers to the way in which the members of a data structure are aligned and how much space, if any, is left between the members. The packing problem is encountered when passing data structures between computers that use different operating systems and/or compilers. Different compilers may pack data structures differently because they use different criteria to determine how to pack their structures. Some compilers will align each data structure member on a 32-bit boundary. Some use other boundaries. When this happens the software using the data structure must use the same packing and therefore have the same gap between structure members. Often this is simply not possible. In most cases the data structures will be hand packed by laboriously adding appropriately sized dummy members in the gaps to simulate compiler packing and the members must still be aligned properly. Once the data structures are hand packed, the programs are then compiled using special flags to turn off any packing operations that would normally be performed. This results in a situation similar to the atomic storage problem, and upgrades to the programs require re-packing and re-compiling.
Configurations of any size are typically stored on disk in a Reserved Disk Area (RDA). Other items such as firmware code images and device error logs may also be stored in the RDA. Very small configurations may also be stored in non-volatile RAM type devices directly on the controller cards. These non-volatile RAM type devices are usually much more expensive than disk, perhaps dollars per megabyte rather than pennies per megabyte; therefore usage is limited.
A problem with configuration storage arises if fixed data structures are used. A firmware upgrade is often required that implements new configuration features, for example, changes the data structure members in some way, and may have to use special code to convert the old structures to the new structures. The converted or xe2x80x9cnewxe2x80x9d structures may require some means of indicating that they have been converted. Often a flag of some sort must be incorporated into the new configuration. Converting the old configuration data to the new configuration""s format is a risky operation if only one copy of the configuration is maintained in the RDA. This is because there is a point when the old data structures are effectively eliminated from the RDA and the new data structures have not yet been written to the RDA. A power failure in mid-write will leave the RDA with a configuration that is only partially updated.
Another problem associated with storage is portability. A customer may want to move all or some of the disks from one controller system to another. If both controller processors are the same then the disks are portable and the configuration on the moved disks may be used without modification. If they are not the same, perhaps one is Big-Endian and the other is Little-Endian, then the problems described above will surface and there will be a severe risk of data loss due to configuration problems.
The process of creating configurations also makes implementation of a configuration standard difficult. Configurations are usually created using special purpose software. The software usually includes some form of graphical user interface (GUI). The GUI is a maintenance problem in itself. Anytime a new feature is added components in the GUI will have to change. Examples are fields that must be made larger, display boxes that require scrolling and new dialogs that are needed. Sometimes a new feature will mean the text configuration has to change to incorporate the new feature; usually this will be a new section consisting of all new keywords.
One of the most elementary problems with a configuration standard is the large number of vendor unique (VU) commands required, or in any event used by, the various controllers. Each manufacturer incorporates their own set of special commands into their controllers in order to support various functions. Because of certain restrictions, such as allowed maximum data size, the number of VU commands can be unwieldy.
Therefore there remains a need for a configuration standard that overcomes the problems discussed above to allow a variety of computer systems and RAID controllers to be used together to more effectively utilize computer resources.
The present invention provides a computer system, a controller, method and computer program for implementing a controller configuration that overcomes the problems discussed above.
In an embodiment of the present invention, ASCII text, such as for example ASCII English text (7 bit) or other text or symbol based string is used to create the configuration, and any text or symbol editor can be used to make changes. Configuration information is described in strictly defined keywords and attributes. The configuration may be stored on disk or other suitable storage media and transferred to and from the controller in symbol strings, for example, in ASCII text composed of strings. For simplicity we refer to all such symbol or symbol based strings as text. The text may be organized into functional blocks delineated by strings.
The configuration of the present invention is portable across virtually all controller platforms. Using text to transfer configuration information avoids problems such as Big-Endian/Little-Endian and data structure member packing. Parser-generators operated by the controller and host computer allow the controller and host computer to receive the configuration information in text form and convert it into native data structures. The configuration of the present invention may be stored on disk in multiple copies as well as in nonvolatile memory of the controller in a strictly controlled manner that allows easy access. Write locks are advantageously used to protect against power failures during updates to the configuration.